29장. AI 코딩을 안전하게 쓰는 방법

앞 장에서는 AI와 함께 코드를 작성하는 방법을 살펴보았다.

AI에게 요구사항을 설명하고, 기존 코드를 분석시키고, 리팩토링을 요청하고, 테스트 코드를 만들게 하는 흐름을 다뤘다.
중요한 것은 AI에게 한 번에 큰 작업을 맡기는 것이 아니라, 작은 단위로 나누어 요청하고 결과를 검토하는 것이라고 했다.

이번 장에서는 한 단계 더 중요한 주제를 다룬다.

바로 AI 코딩을 안전하게 쓰는 방법이다.

AI 코딩 도구는 개발 속도를 높여준다.
하지만 속도가 빨라진다는 것은 잘못된 코드도 더 빨리 만들어질 수 있다는 뜻이다.

AI가 만든 코드는 문법적으로 맞아 보일 수 있다.
IDE에서 오류가 안 날 수도 있다.
테스트 일부가 통과할 수도 있다.

하지만 그것만으로 안전한 코드는 아니다.

실무에서 중요한 것은 단순히 “동작하는 코드”가 아니다.

- 요구사항에 맞는가
- 기존 구조와 맞는가
- 보안 문제가 없는가
- 권한 검사가 빠지지 않았는가
- 장애 상황을 고려했는가
- 테스트로 검증했는가
- 운영 중 추적 가능한가
- 팀원이 유지보수할 수 있는가

AI 코딩을 안전하게 사용하려면 AI가 만든 코드를 그대로 믿지 않는 습관이 필요하다.

AI는 좋은 초안을 만들어줄 수 있다.
하지만 최종 판단과 책임은 여전히 개발자와 팀에게 있다.

1. AI가 만든 코드의 위험성

AI가 만든 코드는 위험할 수 있다.

그 이유는 AI가 악의적이기 때문이 아니다.
AI는 개발자의 요청과 주어진 맥락을 바탕으로 가장 그럴듯한 코드를 생성한다.

문제는 “그럴듯한 코드”와 “실제로 맞는 코드”가 다르다는 점이다.

예를 들어 AI에게 이렇게 요청했다고 해보자.

사용자 포인트 차감 API 만들어줘.

AI는 다음과 같은 코드를 만들 수 있다.

public function deductPoint($userIdx, $amount)
{
    $user = $this->userRepository->find($userIdx);

    if (!$user) {
        return false;
    }

    $this->pointRepository->deduct($userIdx, $amount);

    return true;
}

겉으로 보면 간단하고 동작할 것처럼 보인다.

하지만 실무에서는 많은 문제가 있다.

- amount가 0보다 큰지 확인하지 않는다
- 사용자의 잔여 포인트가 충분한지 확인하지 않는다
- 중복 요청을 막지 않는다
- 트랜잭션이 없다
- 차감 이력이 없다
- 실패 시 롤백 기준이 없다
- 누가 어떤 사유로 차감했는지 감사 로그가 없다
- 음수 amount가 들어오면 오히려 포인트가 증가할 수도 있다

코드는 짧고 깔끔해 보인다.
하지만 서비스에 넣기에는 위험하다.

AI가 만든 코드의 위험성은 바로 여기에 있다.

틀린 코드가 복잡하게 보이는 것이 아니라, 오히려 자연스럽고 깔끔해 보일 수 있다.
그래서 더 쉽게 받아들이게 된다.

AI 코딩을 안전하게 쓰려면 먼저 이 점을 인정해야 한다.

AI는 코드를 만들 수 있다.
하지만 서비스의 모든 조건과 운영 리스크를 자동으로 이해하지는 못한다.

2. 컴파일되는 코드와 맞는 코드의 차이

개발자가 AI 코드를 사용할 때 가장 많이 착각하는 것이 있다.

“에러 없이 실행되면 맞는 코드다”라고 생각하는 것이다.

하지만 컴파일되는 코드와 맞는 코드는 다르다.

컴파일되는 코드는 문법적으로 문제가 없는 코드다.
실행되는 코드는 최소한 런타임 오류 없이 동작하는 코드다.
하지만 맞는 코드는 요구사항과 운영 조건을 만족하는 코드다.

예를 들어 다음 코드는 문법적으로 문제가 없을 수 있다.

public function updateEmail($userIdx, $email)
{
    return $this->userRepository->updateEmail($userIdx, $email);
}

하지만 실제 서비스에서는 부족할 수 있다.

- 이메일 형식 검증이 없다
- 이미 사용 중인 이메일인지 확인하지 않는다
- 본인 계정인지 확인하지 않는다
- 이메일 변경 인증 절차가 없다
- 변경 이력을 남기지 않는다
- 관리자에 의한 변경인지 사용자 본인 변경인지 구분하지 않는다
- 캐시나 검색 인덱스 갱신이 없다

이 코드는 실행될 수 있다.
하지만 요구사항에 맞는 코드는 아닐 수 있다.

AI가 만든 코드는 대부분 문법적으로 자연스럽다.
그래서 개발자는 “괜찮아 보인다”고 느끼기 쉽다.

하지만 실무 검토는 문법이 아니라 요구사항 기준으로 해야 한다.

- 이 기능이 실제 정책과 맞는가
- 예외 상황이 처리되는가
- 실패했을 때 데이터가 어중간하게 남지 않는가
- 권한 없는 사용자가 호출할 수 없는가
- 중복 요청이 들어와도 안전한가
- 운영자가 문제를 추적할 수 있는가

맞는 코드는 실행되는 코드보다 더 많은 조건을 만족해야 한다.

컴파일되는 코드와 맞는 코드
컴파일되는 코드는 문법적으로 오류가 없는 코드다.
맞는 코드는 요구사항, 보안, 운영 조건까지 만족하는 코드다.
AI 코드는 컴파일될 수 있지만, 그것만으로 맞는 코드라고 볼 수 없다.

3. AI가 자주 놓치는 부분

AI가 만든 코드에서 자주 빠지는 부분이 있다.

대표적으로 다음과 같다.

- 인증
- 권한
- 입력값 검증
- 트랜잭션
- 중복 요청 방어
- 예외 처리
- 감사 로그
- 개인정보 마스킹
- 성능 고려
- 기존 공통 모듈 사용
- 팀의 코드 스타일
- 장애 대응

AI는 일반적인 코드 패턴을 잘 만든다.

하지만 회사마다 다른 운영 규칙이나 도메인 정책은 잘 모를 수 있다.

예를 들어 회원 탈퇴 기능을 만든다고 해보자.

AI는 사용자 상태를 DELETED로 바꾸는 코드를 만들 수 있다.
하지만 실제 서비스에서는 다음 조건이 필요할 수 있다.

- 보유 포인트가 남아 있으면 탈퇴 불가
- 진행 중인 결제가 있으면 탈퇴 불가
- 방송 중인 사용자는 탈퇴 불가
- 정산 대기 금액이 있으면 탈퇴 불가
- 탈퇴 후 일정 기간 재가입 제한
- 개인정보 파기 대상과 보관 대상 구분
- 탈퇴 이력 저장
- 관리자 감사 로그 저장
- 외부 연동 서비스 해제

AI가 이런 조건을 자동으로 모두 알기는 어렵다.

따라서 AI에게 코드를 맡길 때는 도메인 규칙을 명확히 알려줘야 한다.
그리고 AI가 만든 코드에서 이런 조건이 빠지지 않았는지 검토해야 한다.

AI가 자주 놓치는 부분은 대부분 “코드 문법”이 아니라 “서비스 맥락”이다.

4. 라이선스 문제

AI 코딩 도구를 사용할 때 라이선스 문제도 생각해야 한다.

AI는 많은 코드 패턴을 학습하고, 그와 유사한 코드를 생성할 수 있다.
대부분의 경우 일반적인 코드 패턴은 문제가 되지 않을 수 있다.

하지만 특정 오픈소스 코드와 매우 유사한 코드가 생성되거나, 라이선스 조건을 지켜야 하는 라이브러리를 무심코 사용하게 되는 경우는 주의해야 한다.

예를 들어 AI가 다음과 같이 제안할 수 있다.

이 기능은 특정 라이브러리를 사용하면 쉽게 구현할 수 있습니다.

그리고 코드에 새로운 패키지를 추가할 수 있다.

composer require example/package

또는 다음처럼 npm 패키지를 사용하라고 할 수도 있다.

npm install some-library

문제는 그 라이브러리의 라이선스가 회사 정책과 맞지 않을 수 있다는 점이다.

오픈소스 라이선스는 종류가 다양하다.

- MIT
- Apache 2.0
- BSD
- GPL
- LGPL
- AGPL

모든 라이선스가 같은 조건을 가지는 것은 아니다.
특히 GPL, AGPL 계열은 사용 방식에 따라 소스 공개 의무나 배포 조건이 문제가 될 수 있다.

따라서 AI가 새로운 라이브러리를 제안하면 반드시 확인해야 한다.

- 이 라이브러리를 꼭 써야 하는가
- 회사에서 허용한 라이선스인가
- 최근까지 유지보수되고 있는가
- 보안 취약점 이력이 있는가
- 대체 가능한 표준 기능은 없는가
- 이미 프로젝트에서 사용하는 라이브러리로 해결할 수 없는가

AI가 제안한 라이브러리를 아무 생각 없이 추가하면 의존성이 늘어난다.
나중에 보안 패치, 버전 충돌, 라이선스 검토 부담이 생길 수 있다.

AI가 만든 코드 자체도 마찬가지다.

특정 프로젝트의 코드와 지나치게 비슷한 코드가 생성되었다고 의심되면 그대로 사용하지 않는 것이 좋다.
가능하면 구조를 참고하되, 팀의 방식에 맞게 다시 작성해야 한다.

라이선스란?
소프트웨어를 사용할 수 있는 조건을 정한 규칙이다.
오픈소스라고 해서 아무 제한 없이 사용할 수 있는 것은 아니다.
회사 서비스에 포함할 때는 라이선스 조건을 확인해야 한다.

5. 보안 취약점

AI가 만든 코드에서 가장 주의해야 할 영역 중 하나가 보안이다.

AI는 일반적인 예제 코드를 잘 만든다.
하지만 보안적으로 안전한 코드를 항상 만드는 것은 아니다.

대표적인 보안 문제는 다음과 같다.

- SQL Injection
- XSS
- 인증 누락
- 권한 검증 누락
- 민감 정보 로그 출력
- 파일 업로드 검증 누락
- SSRF
- 경로 조작
- 비밀번호 평문 저장
- 토큰 만료 검증 누락
- 관리자 API 접근 제어 누락

예를 들어 AI가 다음과 같은 코드를 만들었다고 해보자.

$sql = "SELECT * FROM users WHERE email = '" . $email . "'";
$user = $db->query($sql);

이 코드는 SQL Injection 위험이 있다.

사용자가 입력한 값을 SQL 문자열에 직접 붙이고 있기 때문이다.

더 안전한 방식은 Prepared Statement나 Query Builder를 사용하는 것이다.

$user = $db->table('users')
    ->where('email', $email)
    ->first();

물론 Query Builder를 쓴다고 무조건 안전한 것은 아니다.
하지만 입력값을 직접 문자열로 붙이는 방식보다 안전한 방향이다.

AI에게 코드를 요청할 때는 보안 기준을 명시하는 것이 좋다.

SQL 문자열 결합은 사용하지 말고,
Prepared Statement 또는 Query Builder 형태로 작성해줘.

사용자 입력값은 반드시 서버에서 검증해줘.

관리자 API는 권한 체크 위치를 주석으로 표시해줘.

개인정보는 로그에 남기지 말아줘.

AI가 만든 코드 리뷰에서도 보안 항목은 반드시 확인해야 한다.

특히 인증과 권한은 자주 빠진다.

인증은 “누구인지 확인하는 것”이다.
권한은 “그 사람이 이 작업을 해도 되는지 확인하는 것”이다.

로그인한 사용자라고 해서 모든 작업을 할 수 있는 것은 아니다.

예를 들어 사용자가 로그인되어 있어도, 다른 사용자의 정보를 수정하면 안 된다.
관리자라고 해도 모든 관리자에게 정산 변경 권한을 줄 수는 없다.

AI가 만든 코드에서 “로그인 여부”만 보고 “권한”까지 처리했다고 착각하면 위험하다.

6. 비즈니스 로직 오해

AI 코드는 비즈니스 로직을 오해할 수 있다.

비즈니스 로직은 서비스의 실제 규칙이다.

예를 들어 쇼핑몰이라면 주문, 결제, 배송, 환불 규칙이 비즈니스 로직이다.
방송 플랫폼이라면 방송 시작, 시청, 채팅, 후원, 정산, 신고, 제재 같은 규칙이 비즈니스 로직이다.

AI는 이런 규칙을 기본적으로 알지 못한다.

예를 들어 AI에게 후원 취소 기능을 만들어달라고 하면, 단순히 후원 데이터를 삭제하는 코드를 만들 수 있다.

public function cancelDonation($donationId)
{
    return $this->donationRepository->delete($donationId);
}

하지만 실제 서비스에서는 후원 취소가 단순 삭제가 아닐 수 있다.

- 이미 방송 화면에 노출된 후원인가
- BJ 정산에 반영되었는가
- 시청자 포인트는 환불되는가
- 수수료는 어떻게 처리되는가
- 이벤트 랭킹에서 제거해야 하는가
- 채팅 메시지도 삭제해야 하는가
- 악용 방지를 위해 취소 가능 시간이 있는가
- 관리자만 가능한가
- 감사 로그를 남겨야 하는가

AI가 이런 도메인 규칙을 모르면 코드가 틀릴 수 있다.

비즈니스 로직 오해는 문법 오류보다 더 위험하다.

문법 오류는 실행 중에 바로 드러난다.
하지만 비즈니스 로직 오류는 조용히 잘못된 데이터를 만들 수 있다.

예를 들어 정산 금액이 조금씩 틀어지거나, 특정 조건에서만 권한이 우회되거나, 중복 지급이 발생할 수 있다.

따라서 AI에게 도메인 코드를 요청할 때는 반드시 서비스 규칙을 함께 알려줘야 한다.

후원 취소는 데이터를 삭제하지 않는다.

상태만 CANCELED로 변경한다.

이미 정산 완료된 후원은 취소할 수 없다.

취소 시 시청자 포인트 환불 이력을 남긴다.

BJ 정산 예정 금액에서도 차감한다.

모든 처리는 하나의 트랜잭션으로 묶는다.

관리자 ID와 취소 사유를 감사 로그에 남긴다.

이렇게 알려줘야 AI가 더 안전한 초안을 만들 수 있다.

7. 기존 아키텍처와 맞지 않는 코드

AI가 만든 코드가 기능적으로는 맞아 보여도 기존 아키텍처와 맞지 않을 수 있다.

예를 들어 프로젝트가 다음 구조를 사용한다고 해보자.

Controller
→ Service
→ Repository
→ DB

Controller는 요청을 받고, Service는 비즈니스 로직을 처리하고, Repository는 DB 접근을 담당한다.

그런데 AI가 Controller 안에 DB 쿼리를 직접 작성할 수 있다.

public function getUser(Request $request)
{
    $userIdx = $request->get('userIdx');

    $user = DB::table('users')
        ->where('user_idx', $userIdx)
        ->first();

    return response()->json($user);
}

이 코드는 동작할 수 있다.

하지만 팀의 아키텍처와 맞지 않는다.

기존 구조를 무시한 코드가 쌓이면 유지보수가 어려워진다.

- 비즈니스 로직이 여러 곳에 흩어진다
- 테스트하기 어려워진다
- 공통 예외 처리를 적용하기 어렵다
- DB 접근 규칙이 깨진다
- 나중에 모듈 분리가 어려워진다

AI는 프로젝트의 구조를 충분히 알려주지 않으면 일반적인 예제 코드를 만든다.

따라서 AI에게 코드를 요청할 때는 아키텍처 규칙을 명시해야 한다.

우리 프로젝트는 다음 구조를 사용한다.

- Controller는 요청 검증과 응답 반환만 담당한다.
- Service는 비즈니스 로직을 담당한다.
- Repository는 DB 접근을 담당한다.
- Controller에서 DB를 직접 호출하지 않는다.
- 외부 API 호출은 Client 클래스를 통해서만 한다.
- 공통 응답 형식은 ResponseHelper를 사용한다.

이 규칙을 지켜서 코드를 작성해줘.

AI가 만든 코드 리뷰에서도 아키텍처 위반을 확인해야 한다.

- Controller가 너무 많은 일을 하지 않는가
- Service가 DB 세부 구현에 너무 의존하지 않는가
- Repository에 비즈니스 로직이 들어가지 않았는가
- 공통 모듈을 무시하고 새로 만들지 않았는가
- 기존 예외 처리 방식을 따르는가

좋은 코드는 기능만 맞는 코드가 아니다.
기존 시스템 안에서 자연스럽게 유지보수될 수 있어야 한다.

8. 테스트 없는 AI 코드의 위험

AI가 만든 코드에서 가장 위험한 상황은 테스트 없이 병합하는 것이다.

AI가 만든 코드는 빠르게 보인다.
그래서 작은 기능은 “그냥 넣어도 되겠지”라고 생각하기 쉽다.

하지만 AI 코드는 사람 코드와 똑같이 버그가 있을 수 있다.
오히려 개발자가 완전히 이해하지 못한 상태로 받아들이면 더 위험하다.

예를 들어 AI가 중복 요청 방어 없이 포인트 차감 코드를 만들었다고 해보자.

요청이 한 번만 들어오면 정상 동작한다.
하지만 사용자가 버튼을 두 번 누르거나, 네트워크 재시도로 같은 요청이 두 번 들어오면 포인트가 두 번 차감될 수 있다.

이 문제는 단순 정상 케이스 테스트로는 잡기 어렵다.

테스트할 때는 다음 케이스를 봐야 한다.

- 정상 입력
- 잘못된 입력
- 권한 없는 사용자
- 대상 데이터 없음
- 중복 요청
- 외부 API 실패
- DB 저장 실패
- 트랜잭션 롤백
- 경계값
- 동시 요청

AI에게 테스트 코드를 만들게 할 수도 있다.

이 포인트 차감 기능에 필요한 테스트 케이스를 정리해줘.

정상, 잔액 부족, 음수 amount, 중복 요청, DB 실패, 권한 오류 관점으로 나눠줘.

그리고 실제 테스트 코드도 요청할 수 있다.

위 테스트 케이스를 기준으로 PHPUnit 테스트 코드를 만들어줘.

Repository는 Mock으로 처리하고,
포인트 차감 이력이 저장되는지도 검증해줘.

하지만 AI가 만든 테스트 코드도 검토해야 한다.

자주 생기는 문제는 다음과 같다.

- 테스트가 실제 검증을 하지 않는다
- 실패 케이스가 부족하다
- Mock만 맞추고 실제 동작을 보장하지 않는다
- 동시성 문제를 확인하지 않는다
- 테스트 이름과 검증 내용이 다르다

테스트 없는 AI 코드는 빠르게 병합될 수 있다.
하지만 나중에 운영 장애로 더 큰 비용을 만들 수 있다.

AI가 만든 코드일수록 테스트가 필요하다.

9. 코드 검증 체크리스트

AI가 만든 코드를 검토할 때는 체크리스트를 사용하는 것이 좋다.

사람은 코드가 그럴듯해 보이면 중요한 항목을 놓치기 쉽다.
체크리스트는 이런 실수를 줄여준다.

다음은 AI 코드 검증을 위한 기본 체크리스트다.

이 체크리스트를 모든 코드에 똑같이 적용할 필요는 없다.

간단한 유틸 함수와 결제 API는 위험도가 다르다.
위험한 기능일수록 더 많은 항목을 확인해야 한다.

특히 다음 기능은 강하게 검토해야 한다.

- 결제
- 정산
- 포인트
- 후원
- 인증
- 권한
- 개인정보
- 관리자 기능
- 데이터 삭제
- 외부 API 연동
- 운영 자동화

AI 코드 검증의 핵심은 “잘 돌아가는가”만 보는 것이 아니다.

“잘못될 때 안전한가”까지 봐야 한다.

10. AI 코드 리뷰에서 자주 봐야 할 질문

AI가 만든 코드를 리뷰할 때는 몇 가지 질문을 반복해서 던지는 것이 좋다.

첫 번째 질문은 이것이다.

이 코드를 내가 설명할 수 있는가?

설명할 수 없다면 아직 이해하지 못한 것이다.
AI가 만들었더라도 병합하면 내 코드가 된다.

두 번째 질문은 이것이다.

실패하면 어떻게 되는가?

성공 흐름만 보면 대부분의 코드는 괜찮아 보인다.
하지만 실무 코드는 실패 흐름이 더 중요할 때가 많다.

- DB 저장이 실패하면?
- 외부 API가 timeout 나면?
- 같은 요청이 두 번 오면?
- 중간 단계까지만 성공하면?
- 권한 없는 사용자가 호출하면?
- 로그 저장이 실패하면?

세 번째 질문은 이것이다.

운영자가 추적할 수 있는가?

장애가 나면 로그와 이력이 필요하다.

AI가 만든 코드는 로그가 부족한 경우가 많다.
특히 관리자 기능, 정산, 포인트, 외부 연동은 누가 언제 무엇을 했는지 남겨야 한다.

네 번째 질문은 이것이다.

기존 구조를 깨지 않는가?

AI가 더 깔끔한 구조를 제안했더라도 기존 프로젝트와 맞지 않으면 문제가 될 수 있다.

팀 코드에는 일관성이 중요하다.

다섯 번째 질문은 이것이다.

테스트가 요구사항을 검증하는가?

테스트 코드가 있다는 것만으로 충분하지 않다.
그 테스트가 실제 요구사항을 검증해야 한다.

AI 코드 리뷰는 단순 스타일 리뷰가 아니다.
운영 리스크를 줄이는 과정이다.

11. 팀 단위 AI 코딩 가이드라인 만들기

개인이 AI 코딩 도구를 조심해서 쓰는 것도 중요하다.

하지만 팀 단위로 사용한다면 가이드라인이 필요하다.

가이드라인이 없으면 사람마다 사용 방식이 달라진다.

어떤 사람은 운영 로그를 그대로 AI에 넣을 수 있다.
어떤 사람은 개인 계정 AI 도구에 회사 코드를 붙여넣을 수 있다.
어떤 사람은 AI가 만든 코드를 리뷰 없이 PR에 올릴 수 있다.

그래서 팀에서는 최소한의 기준을 정해야 한다.

가이드라인에는 다음 내용이 들어가는 것이 좋다.

- 허용하는 AI 도구
- 금지하는 AI 도구
- 개인 계정 사용 가능 여부
- 회사 코드 입력 가능 범위
- 입력 금지 데이터
- AI 생성 코드 표시 여부
- 리뷰 필수 기준
- 테스트 필수 기준
- 보안 검토 대상
- 라이선스 확인 절차
- 비용 관리 방식
- 계정 회수 방식

예를 들어 다음과 같은 간단한 규칙을 만들 수 있다.

1. API 키, 토큰, 비밀번호, 개인정보는 AI 도구에 입력하지 않는다.

2. 운영 로그를 사용할 때는 사용자 식별 정보를 제거한다.

3. 결제, 정산, 포인트, 개인정보, 관리자 기능은 AI 코드라도 반드시 리뷰를 받는다.

4. AI가 제안한 신규 라이브러리는 라이선스와 유지보수 상태를 확인한 뒤 추가한다.

5. AI가 만든 코드는 테스트 없이 병합하지 않는다.

6. AI가 파일을 수정한 경우 diff를 확인한다.

7. 대규모 변경은 AI에게 한 번에 맡기지 않는다.

처음부터 너무 복잡한 정책을 만들 필요는 없다.

중요한 것은 팀원이 같은 기준을 공유하는 것이다.

12. PR에서 AI 코드 다루기

AI가 만든 코드도 PR을 통해 리뷰해야 한다.

오히려 AI가 만든 코드일수록 PR 설명이 중요하다.

리뷰어는 이 코드가 어떤 맥락에서 만들어졌는지 알아야 한다.

PR 설명에는 다음 내용을 포함하는 것이 좋다.

- 변경 목적
- AI 도구 사용 여부
- AI가 생성한 범위
- 개발자가 직접 수정한 부분
- 테스트한 내용
- 보안이나 권한 영향
- 운영 영향
- 리뷰어가 집중해서 봐야 할 부분

예를 들어 다음과 같이 작성할 수 있다.

변경 목적:
관리자 사용자 메모 저장 기능 추가

AI 사용 범위:
Service와 Repository 초안 생성에 AI 사용

개발자 수정 사항:
기존 ResponseHelper 적용
관리자 감사 로그 추가
Repository 메서드명을 기존 규칙에 맞게 수정
예외 처리 방식 변경

테스트:
정상 저장
대상 사용자 없음
메모 500자 초과
Repository 예외 발생

리뷰 요청:
관리자 권한 체크 위치와 감사 로그 항목이 적절한지 확인 요청

이렇게 작성하면 리뷰어가 AI 코드를 더 안전하게 검토할 수 있다.

AI 사용 여부를 반드시 공개해야 하는지는 팀 정책에 따라 다를 수 있다.
하지만 적어도 대규모 변경이나 민감 기능에서는 AI 사용 범위를 밝히는 것이 리뷰에 도움이 된다.

PR에서 중요한 것은 “AI가 만들었다”가 아니라 “검토 가능한 형태로 제출되었는가”이다.

13. AI 코딩 가이드라인 예시

팀에서 바로 사용할 수 있는 간단한 AI 코딩 가이드라인 예시를 만들어보자.

AI 코딩 도구 사용 원칙

AI 코딩 도구는 개발 보조 목적으로 사용한다.
AI가 생성한 코드는 초안으로 간주하며, 최종 책임은 코드를 작성하고 병합하는 개발자에게 있다.

입력 금지 정보

다음 정보는 AI 도구에 입력하지 않는다.

- API 키
- 비밀번호
- 인증 토큰
- 세션 값
- 개인정보 원문
- 운영 DB 덤프
- 외부 업체 비밀키
- 내부 보안 정책 문서
- 공개되면 안 되는 장애 로그

운영 로그를 사용할 경우 사용자 식별 정보와 민감 정보를 제거한 뒤 사용한다.

AI 생성 코드 리뷰 기준

다음 영역의 코드는 AI 사용 여부와 관계없이 리뷰를 필수로 한다.

- 결제
- 정산
- 포인트
- 후원
- 인증
- 권한
- 개인정보
- 관리자 기능
- 데이터 삭제
- 외부 API 연동

리뷰 시 다음 항목을 확인한다.

- 요구사항 충족 여부
- 권한 검증
- 입력값 검증
- 예외 처리
- 트랜잭션
- 로그와 감사 추적
- 개인정보 노출 여부
- 테스트 케이스
- 기존 아키텍처 준수 여부

신규 라이브러리 사용 기준

AI가 제안한 신규 라이브러리는 바로 추가하지 않는다.

추가 전 다음 항목을 확인한다.

- 라이선스
- 유지보수 상태
- 보안 취약점 이력
- 기존 라이브러리로 대체 가능 여부
- 번들 크기 또는 성능 영향
- 운영 환경 호환성

작업 단위 기준

AI에게 대규모 변경을 한 번에 맡기지 않는다.

나쁜 예:
회원 도메인 전체 리팩토링해줘.

좋은 예:
이 함수에서 입력값 검증만 분리해줘.
public 메서드 이름과 반환 형식은 유지해줘.

작업은 작은 단위로 나누고, 각 단계마다 diff를 확인한다.

테스트 기준

AI가 만든 코드는 테스트 없이 병합하지 않는다.

최소한 다음 케이스를 검토한다.

- 정상 케이스
- 입력값 오류
- 권한 오류
- 대상 데이터 없음
- 외부 API 실패
- DB 실패
- 중복 요청
- 경계값

이 정도의 가이드라인만 있어도 무분별한 AI 코딩 사용을 줄일 수 있다.

팀의 상황에 따라 더 구체화하면 된다.

14. AI 코딩을 금지해야 하는 영역

AI 코딩 도구를 모든 영역에 똑같이 쓰는 것은 좋지 않다.

일부 영역은 AI 사용을 금지하거나 강하게 제한하는 것이 안전하다.

예를 들어 다음 영역은 주의가 필요하다.

- 운영 DB 직접 수정 스크립트
- 대량 데이터 삭제 스크립트
- 정산 금액 변경 로직
- 결제 승인과 취소 로직
- 개인정보 파기 로직
- 관리자 권한 부여 기능
- 보안 정책 변경
- 인프라 접근 권한 변경
- 배포 자동화 스크립트
- 장애 복구 자동화

이런 영역은 작은 실수가 큰 피해로 이어질 수 있다.

AI를 완전히 쓰지 말라는 뜻은 아니다.
다만 코드를 직접 생성하게 하기보다 검토 보조나 체크리스트 작성에 사용하는 것이 더 안전할 수 있다.

예를 들어 운영 DB 삭제 스크립트를 AI에게 바로 만들게 하는 것은 위험하다.

대신 이렇게 사용할 수 있다.

아래 작업을 수행하기 전에 확인해야 할 위험 요소를 정리해줘.

대량 삭제 작업에서 필요한 백업, dry-run, 트랜잭션, 롤백, 로그 기준을 알려줘.

또는 이렇게 요청할 수 있다.

이 삭제 스크립트가 위험한 이유를 리뷰해줘.

WHERE 조건 누락, 대상 건수 확인, 트랜잭션, 실행 전 백업 관점으로 봐줘.

즉, 고위험 영역에서는 AI를 “실행 코드 생성기”가 아니라 “검토 보조자”로 쓰는 것이 좋다.

dry-run이란?
실제 변경을 수행하지 않고, 어떤 대상이 변경될지만 미리 확인하는 실행 방식이다.
대량 수정이나 삭제 작업에서는 실제 실행 전에 dry-run 결과를 확인하는 것이 안전하다.

15. 안전한 AI 코딩 흐름

AI 코딩을 안전하게 사용하려면 작업 흐름을 정해두는 것이 좋다.

다음은 실무에서 사용할 수 있는 기본 흐름이다.

1. 요구사항 정리
2. 위험 요소 식별
3. AI에게 코드 초안 요청
4. 개발자가 직접 코드 이해
5. 체크리스트 기반 검토
6. 테스트 코드 작성
7. 로컬 실행
8. PR 작성
9. 사람 리뷰
10. 배포 후 로그 확인

이 흐름에서 AI가 할 수 있는 일은 많다.

- 요구사항 질문 목록 작성
- 코드 초안 생성
- 위험 요소 후보 정리
- 테스트 케이스 제안
- PR 설명 초안 작성
- 리뷰 체크리스트 생성
- 문서 초안 작성

하지만 중요한 의사결정은 사람이 해야 한다.

- 요구사항 확정
- 도메인 규칙 판단
- 보안 기준 결정
- 코드 병합 여부
- 배포 여부
- 장애 대응 판단

AI 코딩을 안전하게 쓰는 핵심은 역할 분리다.

AI는 빠른 초안과 검토 후보를 제공한다.
개발자는 최종 판단과 책임을 가진다.

16. 정리

AI 코딩 도구는 개발 생산성을 높여준다.

하지만 AI가 만든 코드는 항상 안전한 것이 아니다.

AI 코드는 컴파일될 수 있다.
실행될 수도 있다.
그럴듯해 보일 수도 있다.

하지만 요구사항과 맞지 않을 수 있다.
권한 검사가 빠질 수 있다.
트랜잭션이 없을 수 있다.
개인정보가 로그에 남을 수 있다.
기존 아키텍처와 맞지 않을 수 있다.
테스트가 부족할 수 있다.

그래서 AI 코딩을 안전하게 쓰려면 다음 원칙을 지켜야 한다.

- AI가 만든 코드는 초안으로 본다
- 컴파일 여부만으로 판단하지 않는다
- 비즈니스 로직을 직접 확인한다
- 인증과 권한을 반드시 검토한다
- 보안 취약점을 확인한다
- 신규 라이브러리는 라이선스를 확인한다
- 기존 아키텍처와 맞는지 본다
- 테스트 없이 병합하지 않는다
- 팀 단위 가이드라인을 만든다
- 고위험 영역은 AI 사용을 제한한다

AI를 잘 쓰는 팀은 AI에게 모든 것을 맡기는 팀이 아니다.

AI가 빠르게 만든 결과를 팀의 기준으로 검토하고, 안전하게 서비스에 반영할 수 있는 팀이다.

앞으로 AI 코딩 도구는 더 강력해질 것이다.
그럴수록 개발팀에는 더 명확한 기준과 리뷰 문화가 필요하다.

AI 코딩의 핵심은 속도가 아니라 안전한 생산성이다.

29장 핵심 요약